home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-pppext-compression-01.txt
< prev
next >
Wrap
Text File
|
1993-10-26
|
34KB
|
1,097 lines
Network Working Group D Rand
Internet Draft Novell
Expires in six months October 1993
The PPP Compression Control Protocol (CCP)
draft-ieft-pppext-compression-01.txt
Status of this Memo
This document is the product of the Point-to-Point Protocol Working
Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the ietf-ppp@ucdavis.edu mailing list.
Distribution of this memo is unlimited.
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
Abstract
The Point-to-Point Protocol (PPP) [1] provides a standard method of
encapsulating multiple protocol datagrams over point-to-point links.
PPP also defines an extensible Link Control Protocol.
This document defines a method for negotiating data compression over
PPP links, and describes the use of several such data compression
protocols.
Dave Rand expires in six months [Page i]
DRAFT PPP Compression October 1993
1. Introduction
PPP has three main components:
1. A method for encapsulating datagrams over serial links.
2. A Link Control Protocol (LCP) for establishing, configuring,
and testing the data-link connection.
3. A family of Network Control Protocols (NCPs) for establishing
and configuring different network-layer protocols.
In order to establish communications over a point-to-point link, each
end of the PPP link must first send LCP packets to configure and test
the data link. After the link has been established and optional
facilities have been negotiated as needed by the LCP, PPP must send
NCP packets to choose and configure one or more network-layer
protocols. Once each of the chosen network-layer protocols has been
configured, datagrams from each network-layer protocol can be sent
over the link.
The link will remain configured for communications until explicit LCP
or NCP packets close the link down, or until some external event
occurs (an inactivity timer expires or network administrator
intervention).
Dave Rand expires in six months [Page 1]
DRAFT PPP Compression October 1993
2. A PPP Control Protocol (NCP) for Compression
The Compression Control Protocol (CCP) is responsible for
configuring, enabling, and disabling data compression algorithms on
both ends of the point-to-point link. It is also used to signal a
failure of the compression/decompression mechanism in a reliable
manner. CCP uses the same packet exchange mechanism as the Link
Control Protocol (LCP). CCP packets may not be exchanged until PPP
has reached the Network-Layer Protocol phase. CCP packets received
before this phase is reached should be silently discarded.
The Compression Control Protocol is exactly the same as the Link
Control Protocol [1] with the following exceptions:
Data Link Layer Protocol Field
Exactly one CCP packet is encapsulated in the Information field of
PPP Data Link Layer frames where the Protocol field indicates type
hex <TBD> (0xFD) (Compression Control Protocol).
Code field
Only Codes 1 through 7 (Configure-Request, Configure-Ack,
Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
and Code-Reject) are used. Other Codes should be treated as
unrecognized and should result in Code-Rejects.
Timeouts
CCP packets may not be exchanged until PPP has reached the
Network-Layer Protocol phase. An implementation should be
prepared to wait for Authentication and Link Quality Determination
to finish before timing out waiting for a Configure-Ack or other
response. It is suggested that an implementation give up only
after user intervention or a configurable amount of time.
Configuration Option Types
CCP has a distinct set of Configuration Options, which are defined
below.
2.1. Sending Compressed Datagrams
Before any compressed packets may be communicated, PPP must reach the
Network-Layer Protocol phase, and the Compression Control Protocol
must reach the Opened state.
One or more compressed packets are encapsulated in the Information
Dave Rand expires in six months [Page 2]
DRAFT PPP Compression October 1993
field of PPP Data Link Layer frames. Each of the compression types
may use a different mechanism to indicate the inclusion of more than
one uncompressed frame in a single PPP Data Link Layer frame. The
Protocol Identifier of the compressed datagram indicates that the
frame is compressed, but not the algorithm with which it was
compressed. Only one algorithm may be in use at time, and that is
negotiated prior to the first compressed frame being transmitted.
The maximum length of a compressed packet transmitted over a PPP link
is the same as the maximum length of the Information field of a PPP
data link layer frame. Larger datagrams (presumably the result of
the compression algorithm increasing the size of the message in some
cases) may be sent uncompressed, using its standard form, or may be
sent in multiple datagrams, if the compression algorithm supports it.
Dave Rand expires in six months [Page 3]
DRAFT PPP Compression October 1993
3. CCP Configuration Options
CCP Configuration Options allow negotiation of compression algorithms
and their parameters. CCP uses the same Configuration Option format
defined for LCP [1], with a separate set of Options.
Configuration Options, in this protocol, indicate algorithms that the
receiver is willing or able to use to decompress data sent by the
sender. As a result, it is to be expected that systems will offer to
accept several differing sets of algorithms, and negotiate down to one
that will indeed be used.
There is the possibility of not being able to agree on a compression
algorithm. In that case, no compression will be used, and the link will
come up without compression. If LAPB has been separately negotiated,
then LAPB will be used (unless it is re-negotiated off).
We expect many vendors to want to use proprietary compression
algorithms, and have made a mechanism available to negotiate these
without encumbering the Internet Assigned Number Authority with
proprietary number requests.
If none of the protocols are not recognized, a Configure-Reject MAY be
sent with the entire, unmodified Configure-Request. The original
transmitter of the Configure-Request, which was hoping to negotiate a
compression of future network data packets sent to it, SHOULD interpret
such a Configure-Reject as indicating that none of the proposed
compression protocols are possible.
If any of the protocols are recognized but not acceptable due to local
options in the request (or optional parameters not in the request), a
Configure-NAK MUST be sent with the local options modified
appropriately. The Configure-NAK SHOULD contain only those protocols
that might be acceptable. Other protocols which are unacceptable,
whether because unrecognized or for other reasons, MUST NOT be listed in
the option in the Configure-NAK. A new Configure-Request MAY then be
sent with the options adjusted as specified in the Configure-Nak.
The most up-to-date values of the CCP Option Type field are specified in
the most recent "Assigned Numbers" RFC [6]. Current values are assigned
as follows:
CCP Option Meaning
1 Compression type negotiation (common)
2 Compression type negotiation (OUI/proprietary)
Dave Rand expires in six months [Page 4]
DRAFT PPP Compression October 1993
3.1. Compression Type Negotiation Option (common)
Description
This Configuration Option provides a way to negotiate the use of a
standard compression algorithm. As of this writing, several
compression algorithms are specified (see appendix). By default,
compression is not enabled.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Comp. Types |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
1
Length
>= 3
Comp. Types (Compression Types)
The compression types field lists the common compression
algorithms that the are available. They must be listed in the
order of desirability for this particular link. Each compression
type is followed with a length, which may be 0. The length
indicates the number of octets of compression-specific negotiation
information, which may include items such as dictionary size,
maximum string length and number of dictionaries.
The receiver will process the compression types field from left to
right, selecting the first protocol that matches the receiver's
capability. If an acceptable compression protocol with acceptable
options is encountered, the Configure-Request MUST be ACK'ed. The
ACK MUST list only this acceptable protocol
If no completely acceptable protocol is found, but one or more
protocols are understood, but some or all of the compression
negotiation options are not acceptable, these may be modified and
sent back in a Configure-Nak.
If none of the protocols are understood or no acceptable alternate
Dave Rand expires in six months [Page 5]
DRAFT PPP Compression October 1993
compression negotiation options are possible, a Configure-Reject
MUST be transmitted. This Configure-Reject MUST be identical to
the original Configure-Request as required by PPP protocols.
Implementation of any particular compression algorithm IS NOT
guaranteed. If all protocols the sender implements are
Configure-Rejected by the receiver, then no compression is
enabled.
Default
No compression protocol enabled.
Dave Rand expires in six months [Page 6]
DRAFT PPP Compression October 1993
3.2. Compression Type Negotiation Option (OUI/Proprietary)
Description
This Configuration Option provides a way to negotiate the use of a
proprietary compression protocol. By default, such compression is
not enabled. Since the first matching compression will be used,
it is recommended that any known OUI compression options be
transmitted first, before the common options are used. Before
accepting this option, the implementation must verify that the
Organizationally Unique Identifier identifies a proprietary
algorithm that the implementation can decompress, and that any
vendor specific negotiation options are fully understood. If no
OUIs are supported by an implementation, a Configure-Reject may be
sent back for any type 2 Compression Type Negotiation Option.
A summary of the Proprietary Compression Algorithm Configuration
Option format is shown below. The fields are transmitted from left
to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | OUI MS octet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI remaining octects | Length | options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
2
Length
>= 3
IEEE OUI
The vendor's IEEE Organizationally Unique Identifier (OUI), which
is the most significant three octets of an Ethernet Physical
Address, assigned to the vendor by IEEE 802. This identifies the
option as being proprietary to the indicated vendor.
Multiple proprietary compression types may be offered, each with a
different OUI, by sending them out after a REJect for any previous
OUI has been received by the sender. When a supported vendor-
specific proprietary compression is seen, and the option field is
valid, a Configure-Ack may be sent to indicate acceptance of this
Dave Rand expires in six months [Page 7]
DRAFT PPP Compression October 1993
compression type.
Multiple vendor-specific proprietary compression types may be
implemented by the option field, which may contain algorithm
selection information, negotiated options such as dictionary size,
or any other information required. If the information in the
option field is unrecognized, a Configure-Reject MUST be sent. If
the information in the option field is recognized, but certain
value(s) are unavailable, a Configure-Nak MAY be sent with the
appropriate values modified.
Any unrecognized proprietary compression configure request MUST
have a Configure-Reject sent back.
Length
The Length field specifies the number of octects of OUI-specific
negotiation information, in free format. It may be followed by 0
to 255 octets of negotiation information.
options
The options field is zero or more octets and contains additional
data as determined by the vendor's compression protocol.
Default
No proprietary compression protocol enabled.
Dave Rand expires in six months [Page 8]
DRAFT PPP Compression October 1993
A. Common compression number identification
The following numbers for common compression option use have been
defined.
Compression ID Algorithm specified
1 Predictor type 1
2 Predictor type 2
3 Puddle Jumper
16 Hewlett-Packard PPC
17 Stac Electronics LZS
18 Microsoft PPC
19 Gandalf FZA
20 V.42bis compression
21 UNIX LZW Compress
IDs 4-15 are reserved for other freely-available implementations
of compression algorithms.
Dave Rand expires in six months [Page 9]
DRAFT PPP Compression October 1993
B. Common compression algorithm definitions
A compression algorithm that is available without license fees is the
predictor algorithm, defined below. Note that although care has been
taken to ensure that the following code does not infringe any
patents, there is no assurance that it is not covered by a patent.
Use the following code at your own risk.
B.1. Predictor algorithm
Predictor works by filling a guess table with values, based on the
hash of the previous characters seen. Since we are either emitting
the source data, or depending on the guess table, we add a flag
bit for every byte of input, telling the decompressor if it should
retrieve the byte from the compressed data stream, or the guess
table. Blocking the input into groups of 8 characters means that
we don't have to bit-insert the compressed output - a flag byte
preceeds every 8 bytes of compressed data. Each bit of the flag
byte corresponds to one byte of reconstructed data.
Take the source file:
000000 4141 4141 4141 410a 4141 4141 4141 410a AAAAAAA.AAAAAAA.
000010 4141 4141 4141 410a 4141 4141 4141 410a AAAAAAA.AAAAAAA.
000020 4142 4142 4142 410a 4241 4241 4241 420a ABABABA.BABABAB.
000030 7878 7878 7878 780a xxxxxxx.
Compressing the above data yields the following:
000000 6041 4141 4141 0a60 4141 4141 410a 6f41 `AAAAA.`AAAAA.oA
000010 0a6f 410a 4142 4142 4142 0a60 4241 4241 .oA.ABABAB.`BABA
000020 420a 6078 7878 7878 0a B.`xxxxx.
Reading the above data says:
flag = 0x60 - 2 bytes in this block were guessed correctly, 5 and 6.
Reconstructed data is: 0 1 2 3 4 5 6 7
File: A A A A A
Guess table: A A
flag = 0x60 - 2 bytes in this block were guessed correctly, 5 and 6.
Reconstructed data is: 0 1 2 3 4 5 6 7
File: A A A A A
Guess table: A A
flag = 0x6f - 6 bytes in this block were guessed correctly, 0-3, 5 and 6.
Reconstructed data is: 0 1 2 3 4 5 6 7
File: A
Guess table: A A A A A A
flag = 0x6f - 6 bytes in this block were guessed correctly, 0-3, 5 and 6.
Reconstructed data is: 0 1 2 3 4 5 6 7
Dave Rand expires in six months [Page 10]
DRAFT PPP Compression October 1993
File: A
Guess table: A A A A A A
flag = 0x41 - 2 bytes in this block were guessed correctly, 0 and 6.
Reconstructed data is: 0 1 2 3 4 5 6 7
File: B A B A B
Guess table: A A
flag = 0x60 - 2 bytes in this block were guessed correctly, 5 and 6.
Reconstructed data is: 0 1 2 3 4 5 6 7
File: B A B A B
Guess table: A B
flag = 0x60 - 2 bytes in this block were guessed correctly, 5 and 6
Reconstructed data is: 0 1 2 3 4 5 6 7
File: x x x x x
Guess table: x x
And now, on to the source - note that it has been modified to work
with a split block. If your data stream can't be split within a
block (eg, compressing packets), then the code dealing with
"final", and the memcpy are not required. You can detect this
situation (or errors, for that matter) by observing that the flag
byte indicates that more data is required from the compressed data
stream, but you are out of data (len in decompress is <= 0). It
*is* ok if len == 0, and flags indicate guess table usage.
#include <stdio.h>
#ifdef __STDC__
#include <stdlib.h>
#endif
#include <string.h>
/*
* pred.c -- Test program for Dave Rand's rendition of the
* predictor algorithm
* Updated by: iand@labtam.labtam.oz.au (Ian Donaldson)
* Updated by: Carsten Bormann <cabo@cs.tu-berlin.de>
* Original : Dave Rand <dlr@bungi.com>/<dave_rand@novell.com>
*/
/* The following hash code is the heart of the algorithm:
* It builds a sliding hash sum of the previous 3-and-a-bit characters
* which will be used to index the guess table.
* A better hash function would result in additional compression,
* at the expense of time.
*/
#define HASH(x) Hash = (Hash << 4) ^ (x)
static unsigned short int Hash;
static unsigned char GuessTable[65536];
Dave Rand expires in six months [Page 11]
DRAFT PPP Compression October 1993
static int
compress(source, dest, len)
unsigned char *source, *dest;
int len;
{
int i, bitmask;
unsigned char *flagdest, flags, *orgdest;
orgdest = dest;
while (len) {
flagdest = dest++; flags = 0; /* All guess wrong initially */
for (bitmask=1, i=0; i < 8 && len; i++, bitmask <<= 1) {
if (GuessTable[Hash] == *source) {
flags |= bitmask; /* Guess was right - don't output */
} else {
GuessTable[Hash] = *source;
*dest++ = *source; /* Guess wrong, output char */
}
HASH(*source++);len--;
}
*flagdest = flags;
}
return(dest - orgdest);
}
static int
decompress(source, dest, lenp, final)
unsigned char *source, *dest;
int *lenp, final;
{
int i, bitmask;
unsigned char flags, *orgdest;
int len = *lenp;
orgdest = dest;
while (len >= 9) {
flags = *source++;
for (i=0, bitmask = 1; i < 8; i++, bitmask <<= 1) {
if (flags & bitmask) {
*dest = GuessTable[Hash]; /* Guess correct */
} else {
GuessTable[Hash] = *source; /* Guess wrong */
*dest = *source++; /* Read from source */
len--;
}
HASH(*dest++);
}
len--;
Dave Rand expires in six months [Page 12]
DRAFT PPP Compression October 1993
}
while (final && len) {
flags = *source++;
len--;
for (i=0, bitmask = 1; i < 8; i++, bitmask <<= 1) {
if (flags & bitmask) {
*dest = GuessTable[Hash]; /* Guess correct */
} else {
if (!len)
break; /* we seem to be really done -- cabo */
GuessTable[Hash] = *source; /* Guess wrong */
*dest = *source++; /* Read from source */
len--;
}
HASH(*dest++);
}
}
*lenp = len;
return(dest - orgdest);
}
#define SIZ1 8192
static void
compress_file(f) FILE *f; {
char bufp[SIZ1];
char bufc[SIZ1/8*9+9];
int len1, len2;
while ((len1 = fread(bufp, 1, SIZ1, f)) > 0) {
len2 = compress((unsigned char *)bufp, (unsigned char *)bufc, len1);
(void) fwrite(bufc, 1, len2, stdout);
}
}
static void
decompress_file(f) FILE *f; {
char bufp[SIZ1+9];
char bufc[SIZ1*9+9];
int len1, len2, len3;
len1 = 0;
while ((len3 = fread(bufp+len1, 1, SIZ1, f)) > 0) {
len1 += len3;
len3 = len1;
len2 = decompress((unsigned char *)bufp, (unsigned char *)bufc, &len1, 0);
(void) fwrite(bufc, 1, len2, stdout);
(void) memcpy(bufp, bufp+len3-len1, len1);
}
Dave Rand expires in six months [Page 13]
DRAFT PPP Compression October 1993
len2 = decompress((unsigned char *)bufp, (unsigned char *)bufc, &len1, 1);
(void) fwrite(bufc, 1, len2, stdout);
}
int
main(ac, av)
int ac;
char** av;
{
char **p = av+1;
int dflag = 0;
for (; --ac > 0; p++) {
if (!strcmp(*p, "-d"))
dflag = 1;
else if (!strcmp(*p, "-"))
(dflag?decompress_file:compress_file)(stdin);
else {
FILE *f = fopen(*p, "r");
if (!f) {
perror(*p);
exit(1);
}
(dflag?decompress_file:compress_file)(f);
(void) fclose(f);
}
}
return(0);
}
B.2. Encapsulation for Predictor type 1
The correct encapsulation for type 1 compression is the protocol
type, 1 bit indicating if the data is compressed or not, 15 bits
of the uncompressed data length in octets, compressed data, and
uncompressed CRC-16 of the two octets of unsigned length in
network byte order, followed by the original, uncompressed data
packet.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CCP Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|*| Uncompressed length (octets)| * is compressed flag
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 means data is compressed
| Compressed data... | 0 means data is not compressed
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC - 16 |
Dave Rand expires in six months [Page 14]
DRAFT PPP Compression October 1993
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The CCP Protocol Identifier that starts the packet is always 0xfd.
If PPP Protocol field compression has not be negotiated, it MUST
be a 16-bit field.
The Compressed data is the Protocol Identifier and the Info fields
of the original PPP packet described in [1], but not the Address,
Control, FCS, or Flag. The CCP Protocol field MAY be compressed
as described in [1], regardless of whether the Protocol field of
the CCP Protocol Identifier is compressed or whether PPP Protocol
field compression has been negotiated.
It is not required that any of the fields land on an even word
boundary - the compressed data may be of any length. If during
the decode procedure, the CRC-16 does not match the decoded frame,
it means that the compress or decompress process has become
desyncronized. This will happen as a result of a frame being lost
in transit if LAPB is not used. In this case, a new configure-
request must be sent, and the CCP will drop out of the open state.
Upon receipt of the configure-ack, the predictor tables are
cleared to zero, and compression can be resumed without data loss.
B.3. Encapsulation for Predictor type 2
The correct encapsulation for type 2 compression is the protocol
type, followed by the data stream. Within the data stream is the
current frame length (uncompressed), compressed data, and
uncompressed CRC-16 of the two octets of unsigned length in
network byte order, followed by the original, uncompressed data.
The data stream may be broken at any convenient place for
encapsulation purposes. With type 2 encapsulation, LAPB is almost
essential for correct delivery.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CCP Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|*| Uncompressed length (octets)| * is compressed flag
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 means data is compressed
| Compressed data... | 0 means data is not compressed
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC-16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|*| Uncompressed length (octets)| * is compressed flag
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
Dave Rand expires in six months [Page 15]
DRAFT PPP Compression October 1993
The CCP Protocol Identifier that starts the packet is always 0xfd.
If PPP Protocol field compression has not be negotiated, it MUST
be a 16-bit field.
The Compressed data is the Protocol Identifier and the Info fields
of the original PPP packet described in [1], but not the Address,
Control, FCS, or Flag. The CCP Protocol field MAY be compressed
as described in [1], regardless of whether the Protocol field of
the CCP Protocol Identifier is compressed or whether PPP Protocol
field compression
It is not required that any field land on an even word boundary -
the compressed data may be of any length. If during the decode
procedure, the CRC-16 does not match the decoded frame, it means
that the compress or decompress process has become desyncronized.
This will happen as a result of a frame being lost in transit if
LAPB is not used. In this case, a new configure-request must be
sent, and the CCP will drop out of the open state. Upon receipt
of the configure-ack, the predictor tables are cleared to zero,
and compression can be resumed without data loss.
C. CCP Recommended Options
The following Configurations Options are recommended:
IP-Compression-Protocol -- with at least 4 slots, usually 16
slots.
IP-Address -- only on dial-up lines.
Security Considerations
Security issues are not discussed in this memo.
References
[1] Simpson, W. A., "The Point-to-Point Protocol", RFC in progress.
[2] Postel, J., "Internet Protocol", RFC 791, USC/Information
Sciences Institute, September 1981.
[3] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, January
1990.
[4] Postel, J., "The TCP Maximum Segment Size Option and Related
Topics", RFC 879, USC/Information Sciences Institute, November
Dave Rand expires in six months [Page 16]
DRAFT PPP Compression October 1993
1983.
[5] Reynolds, J., Postel,J., "Assigned Numbers", RFC 1340,
USC/Information Sciences Institute, March 1990.
[6] Perkins, D., Hobby, R., "Point-to-Point Protocol (PPP) initial
configuration options", RFC 1172, August 1990.
[7] Carr, D., "PPP Gandalf FZA Compression Protocol", Work in
progress.
[8] Lutz, R., "PPP Stacker LZS Compression Protocol", Work in
progress.
[9] Simpson, W.A., "PPP Puddle Jumper Compression Protocol", Work
in progress.
[10] Dimitri, T.J., "PPP Microsoft LZ Compression Protocol", Work in
progress.
Acknowledgments
Some of the text in this document is taken from RFCs 1171 & 1172, by
Drew Perkins of Carnegie Mellon University, and by Russ Hobby of the
University of California at Davis.
Information leading to the expanded IP-Compression option provided by
Van Jacobson at SIGCOMM '90.
The predictor algorithm was originally implemented by Timo Raita, at
the ACM SIG Conference, New Orleans, 1987.
Bill Simpson helped with the document formatting.
Chair's Address
The working group can be contacted via the current chair:
Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, California 93117
(805) 685 4455
Dave Rand expires in six months [Page 17]
DRAFT PPP Compression October 1993
EMail: fbaker@acc.com
Author's Address
Questions about this memo can also be directed to:
Dave Rand
Novell, Inc.
2180 Fortune Drive
San Jose, CA 95131
+1 408 321-1259
EMail: dave_rand@novell.com
Dave Rand expires in six months [Page 18]
DRAFT PPP Compression October 1993
Table of Contents
1. Introduction .......................................... 1
2. A PPP Control Protocol (NCP) for Compression .......... 2
2.1 Sending Compressed Datagrams .................... 2
3. CCP Configuration Options ............................. 4
3.1 Compression Type Negotiation Option (common) .... 5
3.2 Compression Type Negotiation Option
(OUI/Proprietary) ................................................. 7
APPENDICES ................................................... 9
A. Common compression number identification .............. 9
B. Common compression algorithm definitions .............. 10
B.1 Predictor algorithm .......................... 10
B.2 Encapsulation for Predictor type 1 ........... 14
B.3 Encapsulation for Predictor type 2 ........... 15
C. CCP Recommended Options ............................ 16
SECURITY CONSIDERATIONS ................................... 16
REFERENCES ................................................... 16
ACKNOWLEDGEMENTS ............................................. 17
CHAIR'S ADDRESS .............................................. 17
AUTHOR'S ADDRESS ............................................. 18